perf: specialize OnceMap for read-mostly workloads - #241

Summary

• Store Pending and Ready entries directly in one hash table, with waiter coordination allocated only while a value is being initialized.
• Remove the OnceCell and semaphore dependency from the once-map feature without adding dependencies or unsafe code.
• Preserve retry, cancellation, panic, and detached-generation semantics, including waiters that joined an initialization before remove or discard.

Design Notes

A ready entry now retains only its key and Arc<V>. A pending entry owns an Initialization containing the transient wait set; successful publication changes that table entry in place, while failure removes it and wakes one of the joined callers to retry.

hashbrown::HashTable remains as the raw index. Once a non-Clone key has moved into the table, the initializer must locate its exact generation using a precomputed hash and Arc identity; stable std::collections::HashMap does not expose the raw-hash lookup needed to do this without duplicating the key or scanning the map.

Removing permanent coordination has a deliberate cold-path cost: successful first initialization allocates the stored Arc<V> and transitions the table entry after the computation. This favors the intended initialize-once/read-many workload rather than cold insertion throughput. Debug reports entry and pending counts so it does not call user formatting code while holding the table lock.

Benchmark

The table reports the median of four isolated runs of the current OnceMap benchmark through the Cargo benchmark harness on the same machine.

Highly contended 32-thread results varied by path within roughly a 7.6% deterioration to an 11.4% optimization, so this change does not claim a general contention win.

Validation

• cargo x check
• cargo x test
• cargo x lint
• Focused Miri tests for colliding pending entries and removal across generations